home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / iesg / 93_01_25 < prev    next >
Text File  |  1993-08-30  |  12KB  |  287 lines
  1.    
  2.       
  3.                     IETF STEERING GROUP (IESG)
  4.  
  5.                   REPORT FROM THE IETF MEETING
  6.  
  7.                        January 25th, 1993
  8.  
  9.          Reported by:  Greg Vaudreuil, IESG Secretary
  10.  
  11. This report contains IESG meeting notes, positions and action items.
  12.  
  13. These minutes were compiled by the IETF Secretariat which is supported
  14. by the National Science Foundation under Grant No. NCR 8820945.
  15.  
  16. For more information please contact the IESG Secretary.
  17. iesg-secretary@cnri.reston.va.us.
  18.  
  19.  
  20. ATTENDEES
  21. ---------
  22.  
  23.     Almquist, Philip / Consultant
  24.     Borman, David / Cray Research
  25.     Chapin, Lyman / BBN
  26.     Crocker, Dave / TBO
  27.     Crocker, Steve / TIS
  28.     Davin, Chuck / Bellcore
  29.     Gross, Philip / ANS
  30.     Hinden, Robert / SUN
  31.     Hobby, Russ / UC-DAVIS
  32.     Knowles, Stev / FTP Software
  33.     Reynolds, Joyce / ISI
  34.     Piscitello, Dave/ Bellcore
  35.     Stockman, Bernard / SUNET/NORDUnet
  36.     Vaudreuil, Greg / CNRI
  37.  
  38. Regrets
  39.     Coya, Steve / CNRI
  40.     Huizer, Erik / SURFnet
  41.  
  42.  
  43. MINUTES
  44. -------
  45.  
  46. Administrivia
  47.  
  48.  o Approval of the Minutes
  49.  
  50.    The minutes of the January 4th and January 11th IESG Teleconferences
  51.    were approved. 
  52.  
  53.  o Next Meeting
  54.  
  55.    The next IESG teleconference was scheduled for February 1st, 11:30 ET.
  56.  
  57. Protocol Actions
  58.  
  59.  o PEM
  60.  
  61.    The IESG approved PEM for Proposed Standard status.  The notification
  62.    was  reviewed and approved with additions from Bob Hinden to clarify
  63.    the patent situation and meet the requirements of RFC-1310 and minor
  64.    revisions from Steve Crocker.  Hinden proposed wording to be added
  65.    to each of the protocol documents to call attention to the patents
  66.    referenced.  The IESG agreed this was a good idea and that it should
  67.    be done by the RFC Editor.  Discussion on the generic issue is
  68.    recorded under "technical management".
  69.  
  70. ACTION: Vaudreuil -- After the changes are made to the PEM
  71. notification, send it to the RFC Editor and the IETF list.
  72.  
  73.  o SMTP Extensions
  74.  
  75.    The SMTP Extensions document is being reviewed by the Area
  76.    Director.  New versions reflecting changes resulting from the review
  77.    are expected.
  78.  
  79.  o String Representation
  80.  
  81.    New documents are still expected from Steve Hardcastle-Kille.
  82.  
  83.  o Dynamic Host Configuration
  84.  
  85.    Review of the DHC documents by the Area Directors has resulted in a
  86.    significant list of technical and editorial changes.  New documents
  87.    are expected in the next week or so.
  88.  
  89.    A new version of the BootP options was published as an RFC by the
  90.    IANA.  BootP and DHC use the same option number space and the new
  91.    IANA document contains option numbers which were also assigned in an
  92.    incompatible manner in the DHC options document.  The revised
  93.    documents from the DHC Working Group are expected to be coordinated
  94.    with the IANA.
  95.  
  96. ACTION: Almquist -- Insure that the next version of the DHC options
  97. document and the IANA registered BootP options are compatible.
  98.  
  99.    Security has been addressed in some of the DHC documents.  There
  100.    does not appear to have been a comprehensive review of the security
  101.    aspects of this protocol and Steve Crocker was tasked to conduct a
  102.    review resulting in new security considerations section.
  103.  
  104. ACTION: SCrocker -- Conduct a review of the DHC protocols for security
  105. related issues.
  106.  
  107. Technical Management Issues
  108.  
  109.  o Patent considerations in Standards Track Documents
  110.  
  111.    The PEM documents break new ground wrt patents.  The suggestion was
  112.    made and accepted by the IESG that standards track documents
  113.    referencing patents indicate such in the document. It is expected
  114.    that the next version of RFC 1310 will contain sample text for this
  115.    section.
  116.  
  117. POSITION: Standards Track specifications should include a special
  118. section to indicate patent dependence or known legal infringements.
  119.  
  120.  o IP Addressing Guidelines
  121.  
  122.    A single topic meeting was held to clarify the IP addressing
  123.    guidelines.  The conclusion that CIDR was an architectural plan with
  124.    several parts, some of which are standards track and some of which
  125.    are informational, was reviewed and endorsed by the IESG. The action
  126.    plan outlined in the minutes of that meeting was approved
  127.  
  128.  o SNMP Security Issues
  129.  
  130.    Security aspects of SNMP involves fundamental aspects of the SNMPV2
  131.    protocol, especially the naming structure.  Use of parties for
  132.    security affects the application of proxy agents which is
  133.    fundamental to the ability of SNMP to scale. There are proposals to
  134.    separate security from SNMPv2, but it is not clear that a separation
  135.    will help resolve the issues.   The IESG discussed a special
  136.    teleconference for this topic but did not reach closure.
  137.  
  138. RFC Editor Actions
  139.  
  140.  o SNMP over Various Transports
  141.  
  142.    Specific text in the set of three documents specifying transport
  143.    mappings for SNMP over non-udp transport was called into question
  144.    after the IESG approved them for publication.  The text in question
  145.    refers to the use of security with SNMP, a topic under continuing
  146.    discussion.  The IESG decided that the SNMP over Foo documents
  147.    should be published with the understanding that, although the
  148.    documents specify identifiers for SNMP transport domains that may be
  149.    needed when SNMP security mechanisms are in use, the documents are
  150.    equally applicable whether or not SNMP security mechanisms are
  151.    present.
  152.  
  153.    Further, the documents themselves are silent on the question of what
  154.    versions of the SNMP should be supported by standardized security
  155.    mechanisms, and are therefore not inconsistent with any emerging
  156.    community consensus on this question.
  157.  
  158. ACTION: Vaudreuil -- Send a note to the RFC Editor indicating that the
  159. SNMP over Various Transport documents should be published with suggested 
  160. editorial changes to reduce confusion with the current SNMP Security work.
  161.  
  162.  o Wide Area Routing with RIP
  163.  
  164.    The RFC Editor has sent the IESG a document submitted to him for
  165.    Proposed Standard.  The IESG accepted this proposal as a work item
  166.    and Hinden took an action to review the document.
  167.  
  168. ACTION: Hinden -- Review the Wide Area Routing with RIP and determine
  169. an appropriate IETF forum for consideration of this proposal.
  170.  
  171.  o FTP/FTAM Gateway
  172.  
  173.    The RFC Editor has requested clarification from the IESG on two
  174.    points before publication, the standardization of a gateway document
  175.    and the assumption of POSIX filenames in the protocol. 
  176.  
  177.    The IESG agreed that gateway mappings between protocol stacks where
  178.    information loss is possible is subject to standardization.  This is
  179.    consistent with the earlier action to standardize RFC822/RFC821 to
  180.    X.400 mappings. The use of POSIX filename conventions will be
  181.    re-considered before progression to Draft Standard. Any problems
  182.    resulting from the use of POSIX filename conventions will uncovered
  183.    in the process of implementation and operational testing.
  184.  
  185. ACTION: Vaudreuil -- Communicate the IESG understanding on the issues
  186. raised with the FTP/FTAM gateway to the RFC Editor.
  187.  
  188.  
  189.  
  190. Appendix -- Summary of Action Items
  191.  
  192. ACTION: Vaudreuil -- After the changes are made to the PEM
  193. notification, send it to the RFC Editor and the IETF list.
  194.  
  195. ACTION: Almquist -- Insure that the next version of the DHC options
  196. document and the IANA registered BootP options are compatible.
  197.  
  198. ACTION: SCrocker -- Conduct a review of the DHC protocols for security
  199. related issues.
  200.  
  201. ACTION: Vaudreuil -- Send a note to the RFC Editor indicating that the
  202. SNMP over Various Transport documents should be published with only
  203. small editorial changes to reduce confusion with the current SNMP
  204. Security work.
  205.  
  206. ACTION: Hinden -- Review the Wide Area Routing with RIP and determine
  207. an appropriate IETF forum for consideration of this proposal.
  208.  
  209. ACTION: Vaudreuil -- Communicate the IESG understanding on the issues
  210. raised with the FTP/FTAM gateway to the RFC Editor.
  211.  
  212. Appendix -- Minutes from the IP Addressing Teleconference
  213.  
  214. Minutes recorded by Phill Gross
  215.  
  216. Today we held a conference call to discuss the status of the IP
  217. guidelines document by Yakov and Tony Li.  Bernard Stockman, Jon
  218. Postel, Joyce Reynolds, Phill Gross, Bob Hinden, Peter Ford, Tony Li,
  219. and Yakov Rekhter were on the call.  
  220.  
  221. In a startling display of ontime and underbudget project management (we
  222. finished by 12:50 EST!), we came to agreement on the following points
  223. and proposed approach:
  224.  
  225.    - The R/L IP guidelines document is really an architecture
  226.    statement.   With a title change and some minor
  227.    wordsmithing/re-casting, those assembled on the call would be
  228.    comfortable with publishing the (former) "guidelines" document as an
  229.    architecture statement.
  230.  
  231.    - We felt that all the CIDR-related documents should be pulled
  232.    together and published as an RFC set.  Taken together,these
  233.    documents would form  the CIDR plan.
  234.  
  235.    - We felt there needed to be an overall recommendation from the IESG
  236.    regarding CIDR.  This recommendation would be published as an
  237.    Applicability Statement, and would reference all the relevant
  238.    documents in the set.
  239.  
  240. Therefore, we would like to see the following document set published:
  241.  
  242.    Title                         Status  Comments
  243.    ----------------------------  ------  -------------------------------
  244. 1. "IESG Recommendation for CIDR  PS      This would be an AS.  It will
  245.    and Address Allocation"               describe how all the documents
  246.                                          fit together, especially docs
  247.                                          4. and 5.  Bob Hinden and Phill
  248.                                          Gross took the action for this.
  249.  
  250. 2. "Supernetting: An Address     PS      This would be the CIDR specification.
  251.    Aggregation Strategy"                 Tony took the action to update and
  252.                                          revamp this document accordingly.
  253.                                          This is currently published as 
  254.                                          RFC 1338.
  255.  
  256. 3. "Guidelines for IP Address    PS      This would be the CIDR architecture.
  257.    Allocation"                           Yakov took the action to incorporate
  258.                                          the appropriate changes to re-cast
  259.                                          it (including a title change). This
  260.                                          is currently available as an I-D.
  261.  
  262. 4. "Guidelines for Management    Info    This would be the implementation 
  263.    of the IP Address Space"              plan for CIDR address assignment. 
  264.                                          This is currently published as
  265.                                          RFC 1366.  We may not need to 
  266.                                          republish it.
  267.                                          
  268. 5. "The Schedule"                Info    Claudio (for the FEPG) published 
  269.                                          a US-centric schedule for 
  270.                                          implementing RFC 1366.  As part of 
  271.                                          this document set, we would like 
  272.                                          to see a schedule focused on
  273.                                          the whole Internet.  We hope to
  274.                                          get Claudio's and the FEPG's help
  275.                                          for this.
  276.    Actions:
  277.  
  278.    - Bob/Phill -- Write the IESG recommendation; track overall progress
  279.    - Tony -- Update the Supernetting document  
  280.    - Yakov -- Keep doing the Right Thing on the "Guidelines" document
  281.    - Peter -- Tell Elise and Claudio to call Phill 
  282.    - Phill -- Set up follow-up phoneconf regarding the schedule  
  283.  
  284. Goal: publish all new documents as I-Ds by Feb 15th.  Issue Last Call
  285.       by March 1.  
  286.  
  287.